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REMARKS 

Claims 1-66 are pending in the application. 
Claims 1-66 have been rejected. 

Rejection of Claims under 35 U.S.C. £ 103(a) 

Claims 1-66 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
U.S. Patent Publication 2003/0163593 issued to Knightly ("Knightly") in view of U.S. 
Patent 7,102,997 issued to Sultan ("Sultan"). Applicants respectfully traverse this 
rejection. 

Claims 1, 46, and 54: 

Claims 1, 46, and 54 contain substantially the following: 

receiving information indicating a need to change an amount of data being 

transmitted through a first media access control (MAC) device to a client 
of the first MAC device, wherein 

the information is received from the client when the client determines that 
the client is receiving data at a rate exceeding a set threshold; 
forming a message including an indication to a second MAC device to change a 
rate at which the second MAC device transmits data, wherein 
said forming the message uses the information indicating the need to 
change the amount of data being transmitted to the client; and 

transmitting the message to the second MAC device over a network 

See, e.g., claim 1. Applicants respectfully submit that neither Knightly nor Sultan, alone 
or in permissible combination, teaches each claimed feature. 

The Office Action itself states that Knightly does not disclose that "the client 
determines that the client is receiving data at a rate exceeding a set threshold," a 
proposition with which Applicants agree. The Office Action relies on Sultan as 
purportedly providing this missing disclosure. Office Action, p.3. However, Applicants 
respectfully submit that Sultan does not disclose determining that a client receives data at 
a rate exceeding a set threshold. This is unsurprising since Sultan is directed towards 
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"allocating respective proportions of data transmission capacity of the ring to different 
closed user groups (CUGs), each including a plurality of LAN clients." Sultan, Abstract. 

Allocating transmission bandwidth fairly is not the same as determining that a 
client is receiving data at a rate exceeding a set threshold. One can easily imagine an 
example in which it is determined that a group is transmitting more than its allocated 
share, and is thus depriving other CUGs access to transmit, yet there is no determination 
that any client in the network is being overloaded. In fact, the only determination Sultan 
discloses concerns the aggregate transmission rate of a closed user group (CUG), not the 
reception rate of a MAC client. 

Sultan discloses purportedly using CUGs to reduce the complexity of LAN setup 
by specifically avoiding the need to configure individual clients. See Sultan 1:58-67. 
Applicants, on the other hand, disclose making a determination about a single client's 
acceptable rate of reception. Further, the transmission rate discussed in Sultan is an 
aggregate rate across a CUG. 

The cited sections of Sultan do not even disclose the capability of determining a 
transmission rate on a per client basis, much less a reception rate. See, e.g., Sultan 2:4-9, 
which reads: 

The aggregate rate for a CUG reflects an expected overall traffic demand. 
For example, if a CUG includes ten sources each expected to generate 100 
Kb/s traffic on average, a reasonable aggregate rate specification for the 
CUG might be 1000 Kb/s. There is no need to further specify data rates 
among the individual members of the CUG nor to implement point to 
point connectivity. 

The cited section of Sultan discloses purportedly monitoring and controlling the 
aggregate rate at which a CUG transmits data. The passage the Office Action cites as 
purportedly teaching the claimed feature, "the client determines that the client is 
receiving data at a rate exceeding a set threshold" reads: 

When the threshold 22 is exceeded, the RPR node 12 sends a "throttle" 
message to a selected CUG member indicating that the CUG member 
should reduce its rate of transmission into the network 10, as described 
above with reference to FIG. 2. 
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Sultan 5:1-5. The threshold referred to in the cited section is the maximum allowable rate 
of transmission into the network by a CUG. See, e.g., Sultan 3:51-53 ("Therefore the 
network 10 employs the concept of a per CUG aggregate rate, or a total amount of 
transmission bandwidth available to all users of a CUG.")- Selection of the user in the 
CUG to which to send the throttle message is done using a table of "most active sources." 
Sultan 5:20-23. The cited passage discloses purportedly determining that a group of 
clients is transmitting at an aggregate rate exceeding the network bandwidth threshold 
allocated to the group. Determining that a group is transmitting at too great a rate is not 
the same as determining that a client is receiving at too great a rate. Therefore, Applicants 
respectfully submit that Sultan does not cure the deficiencies of Knightly and that the 
suggested combination does not teach each limitation of claims 1, 46, and 54. 

For at least these reasons, Applicants submit that the suggested combination of 
Knightly and Sultan fails to provide disclosure of all the limitations of independent 
claims 1, 46 and 54, and all claims depending therefrom, and that these claims are in 
condition for allowance. Applicants therefore respectfully request the Examiner's 
reconsideration and withdrawal of the rejections to these claims and an indication of the 
allowability of same. 

Claims 18 and 35: 

Claims 18 and 35 contain substantially the following: 

a first media access control (MAC) device operable to be coupled to a network, 
the first MAC device including control logic configured to prepare a 
message for transmission on the network including an indication to change 
a rate at which another MAC device transmits data; and 

a MAC client coupled to the first MAC device, wherein the MAC client 
comprises 

a buffer for storing data transmitted to the MAC client and 
buffer control circuitry configured to provide information about an amount 
of data stored in the buffer, wherein 

the control logic is responsive to the information about the amount 
of data stored in the buffer to prepare the message. 
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See, e.g., claim 18. Applicants respectfully submit that neither Knightly nor Sultan, alone 
or in permissible combination, discloses each claimed feature. The Office Action itself 
states that Knightly does not teach the claimed feature that "the MAC client comprises a 
buffer for storing data transmitted to the MAC client," as recited in claims 18 and 35. 
Applicants agree. The Office Action relies upon the following section of Sultan as 
purportedly providing this missing disclosure: 

In addition to providing for logical separation of the traffic from different 
CUGs 18, the RPR nodes 12 provide other services on a per-CUG basis. 
In particular, the RPR nodes 12 perform functions pertaining to CUG- 
specific service level agreements (SLAs) that specify the nature of CUG 
traffic and the type of service to be provided by the network 10. 

Sultan 3:19-24. Applicants respectfully submit that the cited passage fails to disclose a 

client comprising a buffer for storing data transmitted to the client. In fact, the cited 

passage doesn't mention a buffer at all. It appears that the Office Action is attempting to 

equate provision of services on a per CUG basis to providing a client comprising a buffer 

for storing data transmitted to the client. Office Action, p.4 ("Sultan teaches a system 

where there is included buffers on a per client basis that are monitored and used for 

sending throttle messages"). Applicants respectfully submit that the two are not 

comparable. Sultan discloses bandwidth allocation services, or enforcement of an 

aggregate rate. Sultan 3:25-35. As already discussed, this simply means that each CUG is 

restricted to transmission of data at a certain rate. The cited sections provide no 

disclosure of a buffer for incoming data, much less one with the specific characteristics 

recited in claims 18 and 35. 

For at least these reasons, Applicants submit that the suggested combination of 
Knightly and Sultan fails to provide disclosure of all the limitations of independent 
Claims 18 and 35, and all claims depending therefrom, and that these claims are in 
condition for allowance. Applicants therefore respectfully request the Examiner's 
reconsideration and withdrawal of the rejections to these claims and an indication of the 
allowability of same. 
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Response to Remarks 

The Office Action includes remarks which state that Applicant is attempting to 
indicate that the buffer is physically located with the MAC client. Office Action, p.9. To 
the contrary, Applicants are attempting to indicate that the buffer is exclusive to the MAC 
client. It is not the physical location that matters, but that the buffer contains data 
transmitted to that MAC client, as opposed to buffers which may contain data not 
transmitted to that client. Applicants respectfully submit that the cited references do not 
disclose a buffer for storing data transmitted to a MAC client coupled to a given MAC 
device, but instead disclose transit buffers (which may contain traffic not transmitted to 
the MAC client coupled to the given MAC device) and buffers for storing data 
transmitted by the MAC client. Clearly traffic not transmitted to the MAC client and 
traffic transmitted by the MAC client are not the same as traffic transmitted to the MAC 
client. 
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CONCLUSION 



In view of the amendments and remarks set forth herein, the application and the 
claims therein are believed to be in condition for allowance without any further 
examination and a notice to that effect is solicited. Nonetheless, should any issues 
remain that might be subject to resolution through a telephonic interview, the Examiner is 
invited to telephone the undersigned at 512-439-5092. 

If any extensions of time under 37 C.F.R. § 1.136(a) are required in order for this 
submission to be considered timely, Applicant hereby petitions for such extensions. 
Applicant also hereby authorizes that any fees due for such extensions or any other fee 
associated with this submission, as specified in 37 C.F.R. § 1.16 or § 1.17, be charged to 
deposit account 502306. 



Respectfully submitt; 




Shawn Doman 
Attorney for Applicants 
Reg. No. 60,362 
Telephone: (512) 439-5092 
Facsimile: (512)439-5099 
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